SPACE 2

home *** CD-ROM | disk | FTP | other *** search

/ SPACE 2 / SPACE - Library 2 - Volume 1.iso / magazi~1 / 197a / streport.051 < prev

Wrap

Text File | 1988-10-13 | 82.3 KB | 1,868 lines

ST REPORT WEEKLY ONLINE MAGAZINE Monday, SEPT. 5, 1988 Vol II No. 51 =========== APEInc., P.O. BOX 74, Middlesex, N.J. 08846-0074 PUBLISHER GENERAL MANAGER Ron Kovacs R.F.Mariano ======================================================= ST REPORT EDITOR: Thomas Rex Reade PO Box 6672 Jacksonville, Florida. 32236-6672 Headquarters Bulletin Boards ST Report North ST Report South 201-343-1426 904-786-4176 ------------------------------------ ST Report Central ST Report West 216-784-0574 916-962-2566 CONTENTS ======== > From the GM'S Desk..................> TOS IN ROM A Description......... > BOOTSTRAP A SECOND LOOK.............> A Day at the Races-new release.... > The Transputer......................> The Beat Goes On.................. > Pro GEM Windows #2..................> Good Times Ahead.................. > ST REPORT CONFIDENTIAL..............> Latest ST XFORMER NEWS............ ========================================================================= EXCLUSIVELY ON: COMP-U-SERVE ~ GENIE ~ DELPHI ========================================================================= From the GM's Desk: In the past month or two, we have seen the entire scenario change three times as far as Atari is concerned. Of these changes Atari can be held directly responsible for two and therefore be given the credit for having made the changes. The Dram situation is not the fault of Atari but you can be sure they are not sitting still over this matter....Jack Tramiel has been in Washington D.C. (The Hill) attempting to "enlighten" a few of our uninformed legislators....GOOD LUCK TO YOU SIR! The other changes are sure to, in the future, be a veritable golden bonus to the users but for now are rather painful and aggravating to put up with. My hope is that both Atari and the UserBase (Us Too!) can tolerate the inconveniences and clumsiness closely associated with the total, in the field, reorganisation we are witnessing. The time is at hand for all parties concerned to maintain level heads and cool tempers ....we all are aware that an emotional statement will roll on for what seems to be an eternity and produce nothing but more hard feelings and personal attacks this must come to a screeching halt. We at ST Report are dedicated to forthright information without the pressure of any IOUs and when we see what we feel is either hurting Atari or it's users we will indeed make what we find known to all. The Flip side of the coin is treated the same way We shall report fully and completely all positive matter that effect either Atari and/or the Userbase. As of this issue, we will strive to point out to the readers as many of the positive items we can find. Some have asked; why do we reprint certain things we find on the major services? The answer is simple, many of the folks who eventually get to read ST Report have no modem... therefore, everything we have here is "new" to them. We are now opening an extended hand and asking for reader submitted articles. We hope to see full participation by all. Reader Submissions maybe U/Led to any of the services attached to E-Mail or, sent to ST Report via FNET NODE # 350. R.F.MARIANO Gen'l Mgr. APEInc. ------------------------------------------------------------------------- THE "NEW" TOS ============= AUG/88 TOS ROM set, configured for local keyboard and American text. Diskette (D/S) containing: RAM loadable image of TOS, same configuration as ROM Disk cache program "CACHExxx" HDX Hard Disk utility, HINSTALL and associated programs Product Tracking System front-end program "SPRgen" Release Notes for: TOS CACHExxx HDX, HINSTALL etc (modified to 30/60MB hard disks) Draft User Manual for HDX, HINSTALL etc. User guide for Product Tracking System Various programs, files and tools to assist in translation Each subsidiary has been invited to select a small set of Beta sites, and has been requested to ensure that each such site accepts, in writing, certain terms and conditions, including: No copies to be made. Products and documentation are prerelease and without warranty All communications are to be made solely to the Atari subsidiary, and not through public channels. All copies and documentation to be returned to Atari subsidiary on demand. Weekly report indicating name(s) of tester(s), tests performed, observations to be filed with Atari subsidiary each Friday. Any bug reports to be first verified against the currently released hardware/firmware, to ensure problem is with new TOS. We want to know what works as well as what doesn't work. A report of "no problems" is worthless if it is not accompanied by an explanation of what testing has been performed. If a program fails, it is critical that it be tested with other RELEASED configurations, so that it is very clear whether or not the failure is attributable solely to the new TOS. In our testing we have found MANY ill-behaved programs which fail because they appear to access beyond the Mega 4's 4MB RAM limit. I believe they are accessing "just beyond" where they are supposed to, and it's only on the Mega 4 where they run out of physical address space rather than physical memory. Almost all programs which fail this way have been retested on the current TOS and fail in a similar way. This beta release is not the final one. Programs should not be modified to look for the date encwded in this version. PLEASE DO *NOT* CONTACT ANYONE IN ATARI R&D TO SUPPORT THIS BETA TEST. ALL ENQUIRIES SHOULD BE DIRECTED TO THE TECHNICAL MANAGER OF THE APPROPRIATE ATARI SUBSIDIARY, OR TO JOE FERRARI (408-745-2010) IN THE USA. The R&D group must now address the port of TOS to revised and new hardware platforms, and so I would appreciate your NOT disrupting the development activity. We have support groups in place, and they MUST be your first line of support if development of new products is to continue at optimum speed. A summary of the major improvements to TOS follows: Floppy formatting is "more compatible" with IBM-PC format. A file may be moved (i.e. copy/delete) in one operation. File Copy/Delete/Move can be interrupted with "undo". GEM programs can be autobooted from disk. If a name conflict occurs during a file copy, Copy/Skip/Quit are allowed. A folder may be renamed via "Show Info". The static file allocation limit of 400 is removed; limited now by free memory. "Show/Print File" are completely rewritten. File copying on a single floppy system uses all available memory for buffers. "wind_update(FALSE)" is set when recovering from an application crash. All date separators are now "/". File Selector has had major rework: 16 drive buttons. Application can send a "title" string to FSEL. FSEL now takes first <RETURN> on pathname edit as end-of-edit. Static file allocation of 100 files is removed. Long pathnames and "ABORT/CONTINUE" now handled correctly. Preserves current DTA buffer addresses, clip rectangles and default directories. New bindings available. "appl_init" returns version 0130 in global(0). Editable fields may now be followed by non-editable characters in dialog boxes "wind_get()" with field parameter WF_SCREEN returns address/ length of AES menu/alert buffer. "Ptsin" (VDI) allows 512 vertices (true since 4/22/87). "vqt_extent": Pixel errors on some 270 degree rotations are fixed "vq_mouse" reliability enhanced. 40-folder bug alleviated to the point of improbability. A folder only takes up space when "active". Limited now by depth of folders and the accumulated depth of open files. FOLDRxxx still available. "Malloc" restriction of 20 blocks/process lifted. FAT searching code for floppy and hard-disk is MUCH faster. Sector buffering greatly improved, and "CACHExxx" allows expansion. "Frename" can now rename a folder. Archive bit (0x20) fully supported. Time stamps for "." and ".." are now correct. "Fsettime/Fsetdate" match BIOS and GEMDOS values "Fdatime" input value byteswap fixed Major improvements to "Ccon*" and redirection in general OS Pool reduced to same size as 11/20/85 ROMs (pre Mega). This may allow some programs which fail on Mega ROMs to work again. Soft Reset available from Keyboard if using standard keyboard handler. Soft reset by CTRL/ALT/DEL. Cold Boot clears all available memory (CTRL/ALT/right SHFT/DEL). "Rsconf(-2,-1,-1,-1,-1,-1) returns last baud rate value set by Rsconf. Structure of the reserved part of DTA has changed, and remains reserved. Improvements made to detection of media change. THE ABOVE IS A SUBSET OF THE ENHANCEMENTS MADE. THERE ARE MANY MORE, FULLY DOCUMENTED IN THE RELEASE NOTES SENT TO EACH SUBSIDIARY. ---------------------------------------------------------------------- Roy J. Good Product Development, Atari Corporation Views expressed are my own. Atari may agree or disagree; they have the right. ---------------------------------------------------------------------- ************************************************************************** NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE FOR A LIMITED TIME ONLY COMPUSERVE WILL PRESENT $15.00 WORTH OF COMPLIMENTARY ONLINE TIME to the Readers ST REPORT ONLINE ELECTRONIC MAGAZINE NEW USERS SIGN UP TODAY! Call any of the St Report Official BBS numbers (Listed at the top of ST REPORT) or Leave E-mail to St Report, Ron Kovacs or Rex Reade Be sure to include your full mailing address so your Compuserve kit can be immediately mailed to you! Expires 09-30-88 NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE NOTICE ************************************************************************** SPECIAL SUPRA MODEM OFFER!!! ============================ CompuServe's Atari Forums have made very special arrangements with Paramount Products Inc. to offer the members of our forums the chance to upgrade your system to 2400 baud service at a very special price. For a limited time, CompuServe subscribers may purchase the SUPRA CORP. 2400 baud Hayes-compatible modem for the very **LOW** price of just $139.95 !!!!! These are brand new, not reconditioned units, with the full SUPRA CORP. warranty. The SUPRA MODEM uses the Hayes Smartmodem 'AT' command set and operates at 300-1200-2400 baud. It's an outboard unit (not an internal plug-in card) allowing ease of transfer to other computers. Connection is thru the standard RS-232 interface. (Just plug it into the back of your ATARI ST). To take advantage of this special offer, Phone the 800 number listed below or write to: Paramount Products Inc. 1405 S.E. Pacific Blvd. Albany, Oregon 97321 ***** Phone orders: (800)444-4061 ***** Price: $139.95 + shipping UPS ground: add $4.00 UPS Blue label: add $8.00 C.O.D.: add $2.25 MasterCard or VISA accepted Orders will be shipped the next business day If you've been accessing CompuServe at 1200 baud, this is a great way to lower your total online bill since CIS does *NOT* charge a premium for 2400 baud access. (You can get the same amount of information or download the same amount of programs in approximately 1/2 the time as 1200 baud users!) This modem will PAY FOR ITSELF in just a few sessions. -------------------------------------------------------------------------- BOOTSTRAP - A SECOND LOOK ========================= The Sequel ---------- by M. Arthur After writing STSUPORT, (the original name of the essay) I realized that I made a few errors which, though minor, ARE serious enough to require a clarification. I am glad the article appeared in ST REPORT, however I feel this note is needed because ST REPORT is usually under tight scrutiny by Knowledgable ST Users from a wide and diversified readership. I do not wish the few errors in the essay criticizing Atari to become an excuse for dismissing it as "Atari Bashing", I would hope this clears up any errors in the article: BOOTSTRAPPING ATARI. And Now:------- 1) The Timex Sinclair Spectrum QL (not to be confused with the OTHER Timex Sinclairs) wasn't AS FAST as the ST, but was, in many areas, faster or equally as fast as the Amiga. 2) As known by most ST users, the number of colors in each resolution of the ST are the most possible to use while not slowing down the 68000. While this DOES come in handy, there ARE times when many colors are needed (Spectrum 512?), and when slowing down the processor chip as a result is NOT important. This is when the "Extended Resolutions" could be useful. For those unfamiliar with the Extended Color Resolution specs requested, they are: A 512 color Low Resolution, and a 16 Color Medium Resolution, (Like EGA?) out of a palette of 4096 colors if possible, and 16 Shade gray scaling for High Resolution. This would be an "Extended" Color Mode available as options like EXTENDED LOW, EXTENDED MEDIUM, and EXTENDED HIGH RESOLUTION, so the current ST Resolutions would be standard, but that ST Users/Developers wanting better graphics could use any Extended Resolution. This idea SHOULD be done in HARDWARE, as software solutions to problems like this, which usually emulate the preferred feature, like PC Ditto for IBM Emulation, or Spectrum 512, have been slower than if they were done in hardware. And NOT EVERYONE can spend 3000-4000 dollars ,has the time to learn UNIX or, the skill needed to make applications for Atari's 68030 Machine to obtain superior graphics. Contrary to beliefs of a few, having LOTS of colors has also become a fact of life for microcomputers. (EGA, VGA, Mac II, Amiga for examples) If Atari R&D (or the Tramiels) is wary of this idea, ALL they need do is incorporate the Trio routines into the MMU chips and coupled with TOS support having 512 colors at the same time WON'T take up 80-90% of processor time. Which is what Atari WANTED to keep from happening to ST displays, wasn't it? 3) A quote, from BOOTSTRAPPNG ATARI: "There is no reason why Atari could not come out with a Mega board with the Motorola 68851 MMU chip providing the functions of a TRUE MMU, such as memory paging for virtual memory, this would make TOS support of all the 68000 address space easier. Perhaps selling it through DEALERS along with the new ROMs is a way to go. Fact is, using the MMU chip for other purposes, would definately be improving the ST's capabilities in the process." No other logical reason except that the 68000 chip cannot support MMUs of this type, OR hardware memory protection, making use of a 68851 impossible. But.. the 68020, which has been neglected by TOS, Does support the 68851. Thereby making hardware memory protection, and bomb-free multitasking, possible. MT C-SHELL, while a good ST multitasker, is not bomb free, because of the use of the 68000, and while being reliable, isn't that foolproof, just as Multifinder isn't. IF Atari would cause TOS to support the 68020 we would have true multi tasking Along with Mac II emulation, if the 68020 ST were to have an expansion card making the ST meet Mac II resolution and use a 20-25 MHZ 68020 along with an optional hardware "box" that had 2-6 NuBus (Mac II board type) slots. 4) Another quote which isn't QUITE true: "the Mac II, which is..not powerful enough, except in the area of speed" I meant to edit this before I sent it anywhere, but it slipped by. The Mac II is the BEST in some areas of computing, having super graphics and a good design, except for it's speed, which it isn't as good. Atari's 68030 UNIX machine ought to be its main competition, if it doesn't become vapor. 5) The comments relating to piracy are about the ST being perceived as the segment of computers having the most pirates. Perhaps this is a very logical conclusion. When one compares the number of machines in use to the number of the number of pirates that have been caught. However, this is a deceptive impression. The amount of machines in use is in question, some say 225,00 others say 400,000+, we are inclined to go with the higher number, since certain program sales would show this figure to be more accurate.... Ratio and proportion would dictate that the more machines in use, the more pirates...True, but consider this, the more machines in use...the more sales recorded for new releases. This is the fly in the ointment; Each and every Atari ST owner could buy a copy of a new release and a version of it released in the IBM or MAC market would casually out sell it! COUPLED with erratic product supply and the lack of advertising, can anyone expect the publishers and developers for the ST market to be bubbling over with enthusiasm and high expectations? Just ask 'em about the developer's kit. The above comments and corrections were supplied by the Author of the article, A KEEN OBSERVATION.....BOOTSTRAPPING ATARI, Micheal Arthur. We thank him for his candor and sincere attempts for real accuracy. "A little caution outflanks a large cavalry" - Bismarck - -------------------------------------------------------------------------- TOP UPLOADER CONTEST!! ====================== Beginning September 3,1988 till October 3, 1988 ----------------------------------------------- PRIZE LIST ---------- 1st PRIZE:........... 5 hours of Genie connect time non-prime time 2nd PRIZE:........... 3 hours of Genie connect time non-prime time 3rd PRIZE:........... 2 hours of Genie connect time non-prime time RULES: ------ Prizes will be credited to ones account when winners are announced shortly after October 3,1988. We will be awarding 3 prizes for: The MOST files uploaded. Pictures and song files are excluded also non-functioning slideshows. Duplicates will not be counted. Advertising/and or text files are also excluded. Remember uploading is FREE at 300/1200/2400 baud during non-primetime. Get those files to us and win. Besides the prizes, sharing feels good... doesn't it?? <smile> Darlah J <Hudson> Pine Atari Sysop ------------------------------------------------------------------------- NEW RELEASE INFO: ----------------- A DAY AT THE RACES ================== After three years of research and development we are proud to announce "A Day at the Races". It was designed and written by Marshall Lake and Piet Francke and is being distributed by TEAM Software. "A Day at the Races" is a simulation of the horse race track environment. Much more than the horse race itself, this simulation allows you to buy and sell horses, choose jockeys, and of course wager on races. Each horse and jockey have their own distinct attributes and abilities which affect the outcome of each race. Just like at a real track it is up to you to discern which abilities each horse and jockey possess and to attempt to pick the probable winner of the race. It is as close to the real world of horse racing as you can get without going to the track. The actual horse race itself is presented in exciting, nail-biting real time. Dynamic data base files are kept for the horses and the jockeys. All the various statistical items (including horses' past performances) are maintained to assist in an intelligent wager, horse purchase, or jockey selection. "A Day at the Races" is a multi or single player game. This simulation was designed specifically for the Atari ST line of microcomputers. There is nothing like it available for ANY other microcomputer today that we are aware of! Knowledge of horses or the race track is not necessary at all to enjoy "A Day at the Races". The simulation is presented in such a manner as to make it easy for all users to understand. Depth is combined with simplicity to create a real-world environment which can be enjoyed by everyone whether or not they are race track aficionados. "A Day at the Races" operates in the GEM environment, is entirely mouse controlled, and makes full use of the ST's superb graphics and sound. The simulation requires 512K of RAM with TOS in ROM, at least 1 disk drive, and a color monitor. Optional equipment include a second disk drive and a printer. "A Day at the Races" IS installable onto a hard disk drive. Using a printer, you may obtain hard copy output of the Racing Program, the Racing Form, the Cheat Sheet, various standings, and many other statistics that are available. You will, of course, be able to view these items on the screen, also. This program will be available by October 15, 1988. TEAM Software P. O. Box 7332 Washington, D. C. 20044 (703) 533-2132 (603) 679-1211 Please send any comments to MLAKE. ------------------------------------------------------------------------- THE TRANSPUTER ============== Captured from the ST-Report area on The Source. (PARTI) (Atari Users Group) Subject - Atari's new transputer From: anc@camcon.uucp (Adrian Cockcroft) Newsgroups: comp.sys.transputer,comp.sys.amiga,comp.sys.atari.st Subject: Atari/Perihelion Transputer Machine Spec Keywords: transputer atari workstation Message-ID: <986@titan.camcon.uucp> Date: 15 Oct 87 13:37:21 GMT Organization: Cambridge Consultants Ltd., Cambridge, UK Lines: 176 There have been rumours about Atari and Transputers circulating so I thought that I had better get some hard information out there. I have no involvement in Perihelion, neither has my employer although I have been aware of events at Perihelion and know some of the people who work there. I do want one of their workstations however, I rate it as better than a SUN 3/260C+fpa for numbercrunching with a single T800. A presentation was given by Atari and Perihelion at the Cafe Royal in London on 22/9/87, over 100 software developers, hardware manufacturers and press people attended and no restrictions were made on the information presented at the meeting. I attended and this a quick summary of the notes I took at the meeting. First a benchmark reported by Inmos: Multivariate regression analysis IBM PC 45 minutes T800 18 seconds T800 x 4 7 seconds Inmos also had a T800 powered multiuser flight simulator that kept 4 people at a time happy shooting each other down. 4 T800's per user plus a T4 graphics card and a load of T2's handling the joysticks. All in an ITEM box together. The graphics animation was VERY smooth, far better than a SUN3/260C+fpa+gpone flight simulator I have played with. Atari and Perihelion have got together so that Perihelion are designing the hardware and the software for a high performance workstation to be manufactured and sold by Atari. Perihelion Hardware ------------------- Perihelion is headed by Jack Lang in Cambridge, England. Stage 1 Hardware is a Mega ST add-on system intended for software developers. Stage 2 Hardware is a compatible single box workstation. The Mega ST is a front end I/O processor only. The block diagram looks like: --------- ------------- |blitter| | 4 Mb DRAM | ----------- --------------- --------- --------- ------------- | Mega ST | | Interface | |T800-20| | | | kbd I/O |---| Link Adaptor|----| |-------------------- | mouse | | SCSI disk | | | | | | floppy | --------------- --------- ----------- ---------- ----------- | | | | |1 Mb VRAM| |Graphics| 4Mb/s|SCSI | | | ----------- ---------- ---------- 3 ECL buffered | 40 Mb | 20 MHz links | Winch | ---------- The box takes up to 16 Mb on the motherboard (using 4Mbit DRAMS) and has three expansion slots which can take either 4Mb (1Mbit) or 16Mb (4Mbit) of DRAM each for a total in the box of 64 Mb. The expansion slots use a single DIN plug (VME-type) and the 3 ECL buffered links go onto them so that a slot can contain a board with more transputers on it. Size is enough for four T800s + 1 Mb each per card. Graphics cards can also be used to replace the built-in hardware. The Blitter 2D fills at 128 Mpixels/sec, 2D block copy at 16 Mpixels/sec. (It has a novel architecture based on work by Phil Willis at Bath University). Graphics modes: 1280 * 960 * 4 bpp 1024 * 768 * 8 bpp 640 * 480 * 8 bpp 2 screens for animation 512 * 480 * 32 bpp true colour + overlay and tag bits 60 Hz, not sure about interlace. Probably uses Inmos G170 CLUT giving 256K colour shades. SCSI disk uses true DMA synchronous SCSI interface to get 4Mbytes/s, 40Mb is minimum size. A photo of a completed motherboard in box was shown, smaller than an IBM PC box with 3 fair sized slots. Perihelion Software ------------------- This is based in Shepton Mallet, Somerset, England and is headed by Tim King ex of Metacomco, Amigados fame. Operating system called Helios written in C to support single processor workstations, 4 processor workstations, 1000 processor farms or anything in between. Helios is distributed, multiprocessor, multiuser, sympathetic to the Transputer and familiar to Unix users. Tim King has listened to the criticism of Amigados and has avoided a lot of the complaints about that system. It is based on message passing with transparent passing across processors, it uses a client/server model, has per-processor protection and capability based access. Networking and diskless workstations will be supported via the 3 ECL buffered links with no extra hardware. Applications can be written in 3 modes, the traditional single threaded program, unix-like multiple processes at a coarse grain level or parallel algorithms using a medium grain level. Existing TOS/GEM applications can run on the Mega ST front end processor. User Interface -------------- X-11 window system standard. GEM - translating GEM traps on the 68K i/o proc to the T800. GEM running under X-11 may be provided. Standard unix like shell command line interface. Compatibility ------------- MSDOS floppy disk format UNIX(TM) hard disk format UNIX(TM) compatible C library UNIX(TM) command subset Languages --------- C Pascal Lisp Fortran BCPL Occam Development Tools ----------------- Hosted on ST or Unix(TM) or MSDOS or native Asm/link C Debugger Atari's Position ---------------- They are looking for wider markets and will go upmarket into workstation technology. The hardware design will be Atari's property but Helios is already spreading wider, another 4 companies are likely to use it so far. It will be launched at COMDEX as a Mega ST add-on for developers. Development systems available in Dec 87/Jan 88. The standalone system will be launched at Hannover in March 88. Product in the shops in June 88 in the UK. Product in Europe 6 months later and US launch June 89, giving a years head start to the UK software developers and a chance for the machine to gather some applications software before it hits the US. Priced well below Mac II,base level entry price (no winchester or monitor) aimed at 1000 pounds according to Jack Lang. For now they will provide a set of 3 manuals, User Manual, Developers Manual and Technical Manual for 50 pounds, you then become a registered developer and get a priority place in the queue for developers hardware in December. Apply for more information to: Perihelion Software Limited 24 Brewmaster Buildings Charlton Trading Estate Shepton Mallet Somerset BA4 5QE ------------------------------------------------------------------------- ATARI SHOW! ----------- THE FIRST CANADIAN ATARI USER CONVENTION ======================================== NOVEMBER 06, 1988. This is CANADAS first and only Atari user convention this year. This convention is staged and sponsored by "THE TORONTO ATARI FEDERATION" user group. This group maintains 500 members both in the TORONTO/ONTARIO CANADA area and across the country as well as having associate members from around the world. We have a 40 mb 24hr BBS 416-235-0318 available. It has everything anyone would require when using ATARI SYSTEMS. If anyone wants more info on the computer show leave a message on the board and we will be in touch. If this is not convenient contact the people listed below. This unique computer show is dedicated exclusively to ATARI COMPUTER SYSTEMS.This exciting new event promises to be jam packed with information, demonstrations, lectures and hands on work shops. One of the main exhibitors will be Atari Canada, showing off all the latest software as well as its new and innovative products. That's not all, there will be lots of retailers selling their wares as Special Low Convention prices, hardware and software manufacturers displaying their latest products, user groups demonstrating Atari products and selling their PD software disks, lectures by knowledgeable speakers, seminars by prominent developers and even hands-on workshops where the registered participants can actually work on projects under the guidance of an expert. There will be something for everyone. From multi-player adventure games on the 8-bit to business applications for the Atari IBM clones. So, if you are an Atari owner, or plan to be one or just looking for information, this is the place you will want to be. THE FIRST CANADIAN ATARI USERS CONVENTION is being held at THE SKYLINE TRIUMPH HOTEL located just off highway 401 on Keele Street. NOVEMBER 6TH, 1988 from 10:00am to 6:00pm. (Special hotel rates available) Phone:1-800-268-1332. For more information contact: PRESS: (Mike Searl) ..........416/245-5543 EXHIBITORS: (Jim Jorritsma)...416/242-3413 PUBLIC INFO LINE..............416/425-5357 TAF ONLINE BBS (24hr).........416/235-0318 or, Call: Jim Clark, President, Toronto Atari Federation 416/928-1143 For more information send all inquiries to: "TORONTO ATARI FEDERATION" Computer Show 5334 Yonge ST. 1527 WILLOWDALE, ONTARIO CANADA M2N 6M2 ------------------------------------------------------------------------- THE BEAT GOES ON ================ The following is from one of the major online services, we felt it held enough significance to be reprinted here. The staff of ST Report is withholding comment on the following matters. 31-AUG 06:55 General Information RE: Mega/Federated (Re: Msg 6064) From: NEILHARRIS To: MADMODIFIER The service idea for Federated is to start with service on a district basis (covering up to 8 stores) and adding more facilities as volume warrants. Because the stores within a district are close enough together, turnaround will still be minimal -- trucks will be going between the stores daily. This is precisely how the existing regional chains do their service. We can't expect a chain of stores to make the capital investment in a full repair facility for each location right up front. As far as outside sales goes, that, too, is in the works for Federated. And from what I have seen, it is likely that the sales efforts from Federated could be more serious than the lip service some dealers pay to outside sales. Lloyd, getting off the specifics to the general -- the reason we tend to ignore posts like your diatribe (and lately that's what you have been leaving) is because, no matter what move Atari makes, it causes a storm of criticism. You would think that based on the critics, all was fine with the ST market two years back and all the moves since then have been causing the problems. From where I sit, the market was going in the wrong direction then, and efforts have been made (and are continuing to be made) to establish the ST. Furthermore, these efforts are being undermined by a group of people who take perverse pleasure in tearing down what we are trying to build up. Lloyd, you are not even active on CIS, so I doubt you were included in the "gang" label. Why are you so anxious to join the club? Is it a badge of honor? People seem to think we have no plans for future machines. That could not be farther from the truth. There are some good moves being made up in engineering. Good people have been brought in to get the work done. But the user community doesn't seem to want to give them a chance. It is a terrible situation to be in. The reaction here in Sunnyvale is to pull away from the online areas and from the community in general, because all we get is abuse which we cannot counter because we cannot reveal our new products prematurely. From my personal perspective, I am still fighting. Much of the user support and communications efforts in the last few years have been my doing. For a while, it looked like there was going to be a close relationship between Atari and the users. Now, it looks bleak for that prospect. Back to the marketplace. "Rex" seems to think mail order is the answer. Lloyd likes the dealers. From inside the company, we feel very strongly that dealers are the answer, from solid evidence that sales dropped steadily as the product moved into mail order. We have made moves to cement relationships with dealers, which many dealers have appreciated and reacted to favorably. As to Federated, well, it is certainly a bit of a mess that needs to be fixed. But in the few weeks I have been involved with it, I see a lot of potential. At the very least, it brings the focus here much much closer to the "front lines" of the marketplace, where lessons can be learned that will profoundly influence the future direction of the company. Furthermore, there is good potential to develop a group of full-service stores catering to the entire Atari line (and more, of course). 8-bit sales through Federated have been strong, and we're looking at expanding that line. What other dealer could have brought that off? To reiterate the main point from above, every time we make a move there is a storm of criticism, much of it from out of left field. Only time will tell, and if those of us here who are actually fighting the war can stick it out despite all this, I think the outcome will be what we all want -- a robust, thriving line of quality, inexpensive computers. --->Neil 31-AUG 06:59 General Information RE: The Future of TOS From: NEILHARRIS To: ALL Without getting specific in any way, here is a message for everyone: TOS has a future. This information comes after chats with the engineers to find out what they're up to, and with top management here to determine our own level of commitment. TOS has a future. --->Neil 31-AUG 21:57 General Information RE: Mega/Federated (Re: Msg 6100) From: MADMODIFIER To: NEILHARRIS Neil, I want to thank you for your reply, it was appreciated. And no, I'm not really interested in being 'one of the gang of five', but I was told that I had been included as one of the 'gang'. And I don't feel that I 'bash'. When you guys do something right, I tell you so. But when *I feel* that you are doing something wrong, I'm going to tell you that also. Now let me give you my side.......... 1) I don't really care about mail-order. I think you could allow mail-order stores to carry the 520 but it's not that important to me one way or the other. 2) I find that Atari seems to have two sets of rules..one for the independent stores and another for Federated. Why were the independent dealers *required* to be service centers but not the Federated stores? My local dealer was told (and I think he has it in writing) that NO stores locally would be allowed to carry the Mega/Laser unless they had a complete service center. But you don't enforce that rule when it comes to Federated. 3) I understand about district servicing....but couldn't the independents have been allowed the same thing? Two or three local stores would have liked to have carried the Mega/Laser but couldn't because they didn't have service centers in their store. BUT they all could have got together with the one that did have a local store and formed a 'district service center'....but they weren't allowed that option. 4) I think you (and Atari) have a higher regard for the Federated name than the common person/businessman. The vast majority of the people I know, think that Federated is almost a joke. Yes, they'll go there to buy a stereo/tv when they're on sale, but they'd never rate Federated as a 'quality' store. 5) I have no qualms about allowing Federated to carry the ST line. I just believe the independent dealers should be given the same breaks that Federated gets. Told about specials at the same time, etc. This has NOT happened in the past. Radio Shack for years had company stores and independently owned stores and both got along with no problems (most of the independent dealers got rich). But they only had ONE set of rules for both....not two. 6) I've seen and talked to Federated employees that have been to your seminar. Before the seminar they were horrible, now they're just simply bad. 7) I feel (my opinion) the worse thing that Atari could do would be to stop supporting the online services. The ST owners are leary of Atari the way it is, if there were no communications (and that's what there would be....) between the two groups, you'd be in worse shape than you are now. 8) Finally, look at things from our perspective. We've heard promises about changes from Atari for almost three years now....and have seen very few changes (from a users standpoint). We're still waiting for the CD Roms, IBM hardware emulator, PC clones, etc. You tell us that there are new great and glorious things in the works...that's great, but we haven't seen a lot of the past great and glorious things that were promised yet. There's still no national advertising and by reading between the lines in Sam's post (i.e. dram shortage will continue until 1st part of next year), there won't be any national advertising this year. In three years there has been no upgrades to the o/s (the Mega roms don't count...if it hadn't been for the blitter chip, they would have never came out. And 97% of the people can't get them anyway). Yes, I know about the new roms (and I've got a current version)....but there's no upgrade to them. Atari simply fixed some bugs that should have been fixed 2 years ago and made some cosmetic changes (a item selector like CFJ's, show the program/folder names during file transfer, etc.). But nothing major....no support for a 68020, no support for 32-meg partitions, etc. Neil, the average Atari owner feels like the proverbial mushroom, (kept in the dark and covered with manure), so there is a reason that we get 'antsy' at times. Every once in a while we get a pat on the head to pacify us, but nothing substantial (still no blitter for the ST's). I hope this post wasn't a diatribe. I've tried to be calm and rational....giving you my reasons for why I say what I do. I'm on tons of local BBS's across the country (I'm a BBS addict) and a LARGE percentage of ST owners feel even more strongly than I do. It's up to Atari to open up and calm it's users, not me. We need more open communications between Atari and the user base. The "We can't talk about that yet" gets old after 6-8 months. We never hear or have any open communication with Atari, so it's no wonder that we start listening to every rumor that comes down the pike. Lloyd E. Pulley, Sr. ------------------------------------------------------------------------- ANTIC PUBLISHING INC. COPYRIGHT 1988 REPRINTED BY PERMISSION. Professional GEM by Tim Oren Column #2 - Windows, part 2 EXCELSIOR! In this installment, we continue the exploration of GEM's window manager by finding out how to process the messages received by an application when it has a window defined on the screen. Also, beginning with this column, sample C code demonstrating the techniques discussed will be available on SIG*ATARI in DL5. This will allow you to download the code without interference by the CIS text-formatter used by ANTIC ONLINE output. The file for this column is GEMCL2.XMO. All references to non-GEM routines in this column refer to this file. Please note that these files will not contain entire programs. Instead, they consist of small pieces of utility code which you may copy and modify in your own programs. REDRAWING WINDOWS One of the most misunderstood parts of GEM is the correct method for drawing within a window. Most requests for redrawing are generated by the GEM system, and arrive as messages (read with evnt_multi) which contain the handle of the window, and the screen rectangle which is "dirty" and needs to be redrawn. Screen areas may become dirty as a result of windows being closed, sized down, or moved, thus "exposing" an area underneath. The completion of a dialog, or closing of a desk accessory may also free up a screen area which needs to be redrawn. When GEM detects the presence of a dirty rectangle, it checks its list of open windows, and sends the application a redraw message for each of its windows which intersects the dirty area. CAVEAT EMPTOR GEM does not "clip" the rectangle which it sends to the application; that is, the rectangle may not lie entirely within the portion of the window which is exposed on the screen. It is the job of the application to determine in what portion of the rectangle it may safely draw. This is done by examining the "rectangle list" associated with the window. A rectangle list is maintained by GEM for each active window. It contains the portions of the window's interior which are exposed, i.e., topmost, on the screen and within which the app may draw. Let's consider an example to make this clear. Suppose an app has opened two windows, and there are no desk accessory windows open. The window which is topmost will always have only one rectangle in its list. If the two are separate on the screen, then the second window will also have one rectangle. If they overlap, then the top window will "break" the rectangle of the bottom one. If the overlap is at a corner, two rectangles will be generated for the bottom window. If the overlap is on a side only, then three rectangles are required to cover the exposed portion of the bottom window. Finally, if the first window is entirely within the second, it requires four rectangles in the list to tile the second window. Try working out a few rectangle examples with pencil and paper to get the feel of it. You will see that the possible combinations with more than two windows are enormous. This, by the way, is the reason that GEM does not send one message for each rectangle on the list: with multiple windows, the number of messages generated would quickly fill up the application's message queue. Finally, note that every app MUST use this method, even if it only uses a single window, because there may be desk accessories with their own windows in the system at the same time. If you do not use the rectangle lists, you may overwrite an accessory's window. INTO THE BITS First, we should note that the message type for a redraw request is WM_REDRAW, which is stored in msg[0], the first location of the message returned by evnt_multi. The window handle is stored in msg[3]. These locations are the same for all of the message types being discuss. The rectangle which needs to be redrawn is stored in msg[4] through msg[7]. Now let's examine the sample redraw code in more detail. The redraw loop is bracketed with mouse off and mouse on calls. If you forget to do this, the mouse pointer will be over-written if it is within the window and the next movement of the mouse will leave a rectangular blotch on the screen as a piece of the "old" screen is incorrectly restored. The other necessary step is to set the window update flag. This prevents the menu manager from dropping a menu on top of the screen portion being redrawn. You must release this flag at the end of the redraw, or the you will be unable to use any menus afterwards. The window rectangles are retrieved using a get-first, get-next scheme which will be familiar if you have used the GEM DOS or PC-DOS wildcard file calls. The end of the rectangle list has been reached when both the width and height returned are zero. Since some part of a window might be off-screen (unless you have clamped its position - see below), the retrieved rectangle is intersected with the desktop's area, and then with the screen area for which a redraw was requested. Now you have the particular area of the screen in which it is legal to draw. Unless there is only one window in your application, you will have to test the handle in the redraw request to figure out what to put in the rectangle. Depending on the app, you may be drawing an AES object tree, or executing VDI calls, or some combination of the two. In the AES case, the computed rectangle is used to specify the bounds of the objc_draw. For VDI work, the rectangle is used to set the clipping area before executing the VDI calls. A SMALL CONFESSION At the beginning of this discussion, I deliberately omitted one class of redraws: those initiated by the application itself. In some cases a part of the screen must be redrawn immediately to give feedback to the user following a keystroke, button, or mouse action. In these cases, the application could call do_redraw directly, without waiting for a message. The only time you can bypass do_redraw, and draw without walking the rectangle list, is when you can be sure that the target window is on top, and that the figure being drawn is entirely contained within it. In many cases, however, an application initiated redraw happens because of a computed change, for instance, a spreadsheet update, and its timing is not crucial. In this instance, you may wish to have the app send ITSELF a redraw request. The main advantage of this approach is that the AES is smart enough to see if there is already a redraw request for the same window in the queue, and, if so, to merge the requests by doing a union of their rectangles. In this fashion, the "blinky" appearance of multiple redraws is avoided, without the need to include logic for merging redraws within the program. A utility routine for sending the "self-redraw" is included in the down-load for this article. WINDOW CONTROL REQUESTS An application is notified by the AES, via the message system, when the user manipulates one of the window control points. Remember that you must have specified each control point when the window was created, or will not receive the associated control message. The most important thing to understand about window control is that the change which the user requested does not take place until the application forwards it to the AES. While this makes for a little extra work, it gives the program a chance to intervene and validate or modify the request to suit. A second thing to keep in mind is that not all window updates cause a redraw request to be generated for the window, because the AES attempts to save time with raster moves on the screen. Now let's look at each window control request in detail. The message code for a window move is WM_MOVED. If you are willing to accept any such request, just do: wind_set(wh, WF_CXYWH, msg[4], msg[5], msg[6], msg[7]); (Remember that wh, the window handle, is always in msg[3]). The AES will not request a redraw of the window following this call, unless the window is being moved from a location which is partially "off-screen". Instead, it will do a "blit" (raster copy) of the window and its contents to the new location without intervention by the app. There are two constraints which you may often wish to apply to the user's move request. The first is to force the new location to lie entirely within the desktop, rather than partially off-screen. You can do this with the rc_constrain utility by executing: rc_constrain(&full, &msg[4]); before making the wind_set call. (Full is assumed to contain the desktop dimensions.) The second common constraint is to "snap" the x-dimension location of the new location to a word boundary. This operation will speed up GEM's "blit" because no shifting or masking will need to be done when moving the window. To perform this operation, use align() before the wind_set call: msg[4] = align(msg[4], 16); The message code for a window size request is WM_SIZED. Again, if you are willing to accept any request, you can just "turn it around" with the same wind_set call as given for WM_MOVED. Actually, GEM enforces a couple of constraints on sizing. First, the window may not be sized off screen. Second, there is a minimum window size which is dependent on the window components specified when it was created. This prevents features like scroll arrows from being squeezed into oblivion. The most common application constraint on sizing is to snap the size to horizontal words (as above) and/or vertical character lines. In the latter case, the vertical dimension of the output font is used with align(). Also, be aware that the size message which you receive specifies the EXTERNAL dimensions of the window. To assure an "even" size for the INTERNAL dimensions, you must make a wind_calc call to compute them, use align() on the computed values, back out the corresponding external dimensions with the reverse wind_calc, and then make the wind_set call with this set of values. A window resize will only cause a redraw request for the window if the size is being increased in at least one dimension. This is satisfactory for most applications, but if you must "reshuffle" the window after a size-down, you should send yourself a redraw (as described above) after you make the wind_set call. This will guarantee that the display is updated correctly. Also note that the sizing or movement of one window may cause redraw requests to be generated for other windows which are uncovered by the change. The window full request, with code WM_FULLED, is actually a toggle. If the window is already at its full size (as specified in the wind_create), then this is a request to shrink to its previous size. If the window is currently small, then the request is to grow to full size. Since the AES records the current, previous, and maximum window size, you can use wind_get calls to determine which situation pertains. The hndl_full utility in the down-load (modified from Doodle), shows how to do this. The "zoom box" effects when changing size are optional, and can be removed to speed things up. Again, if the window's size is decreasing, no redraw is generated, so you must send yourself one if necessary. You should not have to perform any constraint or "snap" operations here, since (presumably) the full and previous sizes have had these checks applied to them already. The WM_CLOSED message is received when the close box is clicked. What action you perform depends on the application. If you want to remove the window, use wind_close as described in the last column. In many applications, however, the close message may indicate that a file is to be saved, or a directory or editing level is to be closed. In these cases, the message is used to trigger this action before or instead of the wind_close. (Folders on the Desktop are an example of this situation.) The WM_TOPPED message indicates that the AES wants to bring the indicated window to the "top" and make it active. This happens if the user clicks within a window which is not on top, or if the currently topped window is closed by its application or desk accessory. Normally, the application should respond to this message with: wind_set(wh, WF_TOP, 0, 0); and allow the process to complete. In a few instances, a window may be used in an output only mode, such as a status display, with at least one other window present for input. In this case, a WM_TOPPED message for the status window may be ignored. In all other cases, you must handle the WM_TOPPED message even if your application has only one window: Invocation of a desk accessory could always place another window on top. If you fail to do so, subsequent redraws for your window may not be processed correctly. WINDOW SLIDER MESSAGES If you specify all of the slider bar parts for your window, you may receive up to five different message types for each of the two sets of sliders. To simplify things a little, I will discuss everything in terms of the vertical (right hand side) sliders. If you are also using the horizontal sliders, the same techniques will work, just use the alternate mnemonics. The WM_VSLID message indicates that the user has dragged the slider bar within its box, indicating a new relative position within the document. Along with the window handle, this message includes the relative position between 1 and 1000 in msg[4]. Recall from last column's discussion that this interval corresponds to the "freedom of movement" of the slider. If you want to accept the user's request, just make the call: wind_set(wh, WF_VSLIDE, msg[4], 0, 0, 0); (Corresponding horizontal mnemonics are WM_HSLID and WF_HSLIDE). Note that this wind_set call will not cause a redraw message to be sent. You must update the display to reflect the new scrolled position, either by executing a redraw directly, or by sending yourself a message. If the document within the window has some structure, you may not wish to accept all slider positions. Instead you may want to force the scroll position to the nearest text line (for instance). Using terms defined in the last column, you may convert the slider position to "document units" with: top_wind = msg[4] * (total_doc - seen_doc) / 1000 + top_doc (This will probably require 32-bit arithmetic). After rounding off or otherwise modifying the request, convert it back to slider units and make the WF_VSLIDE request. The other four slider requests all share one message code: WM_ARROWED. They are distinguished by sub-codes stored in msg[4]: WA_UPPAGE, WA_DNPAGE, WA_UPLINE, and WA_DNLINE. These are produced by clicking above and below the slider, and on the up and down arrows, respectively. (I have no idea why sub-codes were used in this one instance.) The corresponding horizontal slider codes are: WA_LFPAGE, WA_RTPAGE, WA_LFLINE, and WA_RTLINE. What interpretation you give to these requests will depend on the application. In the most common instance, text documents, the customary method is to change the top of window position (top_wind) by one line for a WA_UPLINE or WA_DNLINE, and by seen_doc (the number of lines in the window) for a WA_UPPAGE or WA_DNPAGE. After making the change, compute a new slider position, and make the wind_set call as given above. If the document's length is not an even multiple of "lines" or "pages" you will have to be careful that incrementing or decrementing top_wind does not exceed its range of freedom: top_doc to (top_doc + total_doc - seen_doc). If you have such an odd size document, you will also have to make a decision on whether to violate the line positioning rule so that the slider may be put at its bottom-most position, or to follow the rule but make it impossible to get the slider to the extreme of its range. A COMMON BUG It is easy to forget that user clicks are not the only things that affect slider position. If the window size changes as a result of a WM_SIZED or WM_FULLED message, the app must also update its sliders (if they are present). This is a good reason to keep the top of window information in "document units". You can just redo the position calculation with the new "seen_doc" value, and call wind_set. Also remember that changing the size of the underlying document (adding or deleting a bottom line, for instance) must also cause the sliders to be adjusted. DEPT. OF DIRTY TRICKS There are two remaining window calls which are useful to advanced programmers. They require techniques which I have not yet discussed, so you may need to file them for future reference. The AES maintains a quarter-screen sized buffer which is used to save the area under alerts and menu drop-downs. It is occasionally useful for the application to gain access to this buffer for its own use in saving screen areas with raster copies. To do so, use: wind_get(0, WF_SCREEN, &loaddr, &hiaddr, &lolen, &hilen); Hiaddr and loaddr are the top and bottom 16-bits (respectively) of the 32-bit address of the buffer. Hilen and lolen are the two halves of its length. Due to a preculiarity of the binding you have to reassemble these pieces before using them. (The actual value of WF_SCREEN is 17; this does not appear in some versions of the GEMDEFS.H file.) If you use this buffer, you MUST prevent menus from dropping down by using either the BEG_UPDATE or BEG_MCTRL wind_update calls. Failure to do so will result in your data being destroyed. Remember to use the matching wind_update: END_UPDATE or END_MCTRL, when you are done. The other useful call enables you to replace the system's desktop definition with a resource of your choosing. The call: wind_set(0,WF_NEWDESK, tree, 0,0); where tree is the 32-bit address of the object tree, will cause the AES to draw your definition instead of the usual gray or green background. Not only that, it will continue to redraw this tree with no intervention on your part. Obviously, the new definition must be carefully built to fit the desktop area exactly or garbage will be left around the edges. For the truly sophisticated, a user-defined object could be used in this tree, with the result that your application's code would be entered from the AES whenever the desktop was redrawn. This would allow you to put VDI pictures or complex images onto the desktop background. A SIN OF OMISSION In the last column, I neglected to mention that strings whose addresses are passed in the WF_NAME and WF_INFO wind_set calls must be allocated in a static data area. Since the AES remembers the addresses (not the characters), a disaster may result if the storage has been reused when the window manager next attempts to draw the window title area. COMING SOON... This concludes our tour of GEM's basic window management techniques. There have been some unavoidable glimpses of paths not yet taken (forward references), but we will return in time. On our next excursion, we will take a look at techniques for handling simple dialog boxes, and start exploring the mysteries of resources and object trees. >>>>>>>>>>>>>>>>>>>>>>>>>> Sample Redraw Code <<<<<<<<<<<<<<<<<<<<<<<<<<<< VOID do_redraw(wh, area) /* wh = window handle from msg[3] */ WORD wh; /* area = pointer to redraw rect- */ GRECT *area; /* tangle in msg[4] thru msg[7] */ { GRECT box; graf_mouse(M_OFF, 0x0L); wind_update(BEG_UPDATE); wind_get(wh, WF_FIRSTXYWH, &box.g_x, &box.g_y, &box.g_w, &box.g_h); while ( box.g_w && box.g_h ) { if (rc_intersect(full, &box)) /* Full is entire screen */ if (rc_intersect(area, &box)) { if (wh == w1_handle) /* Test for window 1 handle */ { /* AES redraw example */ objc_draw(w1_tree, ROOT, MAX_DEPTH, box.g_x, box.g_y, box.g_w, box.g_h); } else if (wh == w2_handle) /* Test for window 2 handle */ { /* VDI redraw example */ set_clip(TRUE, &box); /* Put VDI drawing calls here */ } /* add more windows here */ } wind_get(wh, WF_NEXTXYWH, &box.g_x, &box.g_y, &box.g_w, &box.g_h); } wind_update(END_UPDATE); graf_mouse(M_ON, 0x0L); } >>>>>>>>>>>>>>>>>>>>>>>>> Utilities used in do_redraw <<<<<<<<<<<<<<<<<<<<<<< VOID set_clip(clip_flag, area) /* set clip to specified area */ WORD clip_flag; GRECT *area; { WORD pxy[4]; grect_to_array(area, pxy); vs_clip(vdi_handle, clip_flag, pxy); } VOID grect_to_array(area, array) /* convert x,y,w,h to upr lt x,y and */ GRECT *area; /* lwr rt x,y */ WORD *array; { *array++ = area->g_x; *array++ = area->g_y; *array++ = area->g_x + area->g_w - 1; *array = area->g_y + area->g_h - 1; } WORD rc_intersect(p1, p2) /* compute intersect of two rectangles */ GRECT *p1, *p2; { WORD tx, ty, tw, th; tw = min(p2->g_x + p2->g_w, p1->g_x + p1->g_w); th = min(p2->g_y + p2->g_h, p1->g_y + p1->g_h); tx = max(p2->g_x, p1->g_x); ty = max(p2->g_y, p1->g_y); p2->g_x = tx; p2->g_y = ty; p2->g_w = tw - tx; p2->g_h = th - ty; return( (tw > tx) && (th > ty) ); } >>>>>>>>>>>>>>>>>>>>>>>>> "Self-redraw" Utility <<<<<<<<<<<<<<<<<<<<<<<<<<< VOID send_redraw(wh, p) WORD wh; GRECT *p; { WORD msg[8]; msg[0] = WM_REDRAW; /* Defined in GEMBIND.H */ msg[1] = gl_apid; /* As returned by appl_init */ msg[2] = 0; msg[3] = wh; /* Handle of window to redraw */ msg[4] = p->g_x; msg[5] = p->g_y; msg[6] = p->g_w; msg[7] = p->g_h; appl_write(gl_apid, 16, &msg); /* Use ADDR(msg) for portability */ } >>>>>>>>>>>>>>>>>>>>>> Utilities for Window Requests <<<<<<<<<<<<<<<<<<<< VOID rc_constrain(pc, pt) GRECT *pc; GRECT *pt; { if (pt->g_x < pc->g_x) pt->g_x = pc->g_x; if (pt->g_y < pc->g_y) pt->g_y = pc->g_y; if ((pt->g_x + pt->g_w) > (pc->g_x + pc->g_w)) pt->g_x = (pc->g_x + pc->g_w) - pt->g_w; if ((pt->g_y + pt->g_h) > (pc->g_y + pc->g_h)) pt->g_y = (pc->g_y + pc->g_h) - pt->g_h; } WORD align(x,n) /* Snap position x to an n-bit grid */ WORD x, n; /* Use n = 16 for horizontal word alignment */ { x += (n >> 2) - 1; /* Round and... */ x = n * (x / n); /* remove residue */ return (x); } >>>>>>>>>>>>>>>>>>>>>>>>> Window full utility <<<<<<<<<<<<<<<<<<<<<<<<<< VOID hndl_full(wh) /* depending on current window state, make window */ WORD wh; /* full size -or- return to previous shrunken size */ { /* graf_ calls are optional special effects. */ GRECT prev; GRECT curr; GRECT full; wind_get(wh, WF_CXYWH, &curr.g_x, &curr.g_y, &curr.g_w, &curr.g_h); wind_get(wh, WF_PXYWH, &prev.g_x, &prev.g_y, &prev.g_w, &prev.g_h); wind_get(wh, WF_FXYWH, &full.g_x, &full.g_y, &full.g_w, &full.g_h); if ( rc_equal(&curr, &full) ) { /* Is full, change to previous */ graf_shrinkbox(prev.g_x, prev.g_y, prev.g_w, prev.g_h, full.g_x, full.g_y, full.g_w, full.g_h); wind_set(wh, WF_CXYWH, prev.g_x, prev.g_y, prev.g_w, prev.g_h); /* put send_redraw here if you need it */ } else { /* is not full, so set to full */ graf_growbox(curr.g_x, curr.g_y, curr.g_w, curr.g_h, full.g_x, full.g_y, full.g_w, full.g_h); wind_set(wh, WF_CXYWH, full.g_x, full.g_y, full.g_w, full.g_h); } } WORD rc_equal(p1, p2) /* tests for two rectangles equal */ GRECT *p1, *p2; { if ((p1->g_x != p2->g_x) || (p1->g_y != p2->g_y) || (p1->g_w != p2->g_w) || (p1->g_h != p2->g_h)) return(FALSE); return(TRUE); } Next Week, #3 in the ongoing series........... ANTIC PUBLISHING INC. COPYRIGHT 1988 REPRINTED BY PERMISSION. ------------------------------------------------------------------------- GOOD TIMES AHEAD? ================= by T."Rex Reade Here I sit, staring at the equipment before me saying to myself, "Self, why do you carry on with the folks at Atari like you do and when are you going to realize that those who give the most rediculous answers and replies are the lowest on the totem pole? Well, today I answered that question and by golly, I realized that the TOP BRASS at Atari want the same things I do! It's the turkeys that are making all the problems in the rumor mill and hard feelings department. Therefore, from now on, Self is going to fly with the Eagles and let the turkeys roast themselves. Also, a concentration on the positive aspects of Atari will prevail if at all possible. An important point to make is Atari has a super good concept in the ST computer line and a very weak approach to national marketing. It has been said by a few that I favor the mail order houses...in a way I do and my reason is very simple...there are some dealers who relish charging LIST PRICE for the Atari products....at least mail order stopped the gouge...I know of one dealer who is charging 500.00+ for the older (used) SC1224...he tells folks that the newer monitors are junk compared to the older models..(He offers the new stylish monitor for 100.00 as long as the older one has the box and booklets in his trade-in upgrade deal..cute???) This appears sleezy and detremental to Atari's good name! Others are very busy trying to market multi-sync monitors which is ok as it stands.. but when a "dealer" tries to tell folks it is as good as the SC1224...that dealer needs a "slap!" The SC1224 is a fine RGB monitor and will outperform 99% of what is out there in it's class. We all know the multi-sync is a nice space saver but, it's a compromise on quality in "certain areas" like text in medium resolution....it is not even close to the quality of the SC1224. The "pin cushion" effect on the multisync was more than evident, the SC1224 was just dandy. When the dealers resort to wholesale snake oil sales it is time to rethink the entire program and we believe that is just what Atari is doing....the area representatives do not, as a whole, keep their appointments. The exisiting dealers feel neglected thus, they carry on with the attitude that Atari doesn't care about them, so...let's milk it for all it's worth. The Federated thingy that Neil is trying to polish and groom may just be the answer! Company stores through out the Nation, centralized service centers with pick up and delivery to company stores in that hub, an outside sales force dedicated to commercial sales and application. Folks, I do not think this is a pipe dream, this IS coming down the road. It has to, in order to save the userbase we have and build upon it. There are some very FINE dealers out there who will become a part of the Atari chain of stores and this is good....the time has come for sure, to eliminate the charletans and snake oil merchants from the ranks of good dealers representing Atari. One of the really nice things about encouraging folks to send in their experiences with dealers (good or bad) is the diversification of opinions we receive. Without risking real outcry, it is safe to say, Atari is on the right track in trying to establish a national chain as long as the GOOD dealers are assured of being treated equally and on the same footing as the "company stores". Neil Harris may be many things, but one he will do is try his best to make sure the independents (deserving) get a fair shake throughout the entire big picture. When we hear about bashing and the gang of five and all the other colorful non-sense, we think of hard feelings and emotion. There is no reason for any of this! If one were to really step back and take a long hard look at what the majority of the bashers have been doing, it's simple! Pointing out the shortfall and using any means to obtain the attention of those at Atari who are in as position to bring about change and improvement. As we know there are always those who, in their BLIND faith and hero worship, will defend any premise brought forward by an outspoken person or by an individual who may disagree with one or more critics. Seemingly, these are the folks who have unwittingly perpetuated the SILLY arguments. The Time has come TO ALLOW ATARI the opportunity to SHOW ALL OF US their stuff. Comdex is right around the corner, the new ROMs are due for release (hopefully they read more than 16mb per partition), and they did say we would be proud of the advertising this year....remember the CO during the SPRING COMDEX? WE......shall see. In any case, the time is at hand to demonstrate to all that our support for Atari has not waivered. Nor has any of our faith in JACK TRAMIEL been eroded. Rex............ ------------------------------------------------------------------------- ST REPORT CONFIDENTIAL ====================== Sunnyvale CA Our favorite company may be headed for a very nice ------------ bonus..Seems the folks at Federated "lost" 43million somewhere in the offering...penalties could double the amount for Atari. NYC NY The "Mega4 Deal" is over and now the Mega 2 deal is ------- here! After Labor Day, Dealers will be offering the Mega2 at a very good price....less than 1395.00... certain dealers wanted this kept hush-hush..another reason why the ads are so very neccessary. Norcross GA. Hayes Micro, has been inundated with a super positive ------------ response for its special Sysops modem discount offer. Delivery time is hovering around three to eight weeks. Jacksonville FL. ABCO Hard Disks announced the new 130mb Hard Drive --------------- System is highly successful and like it's predecessors it is fully upgradable. Sunnyvale CA The New TOS in ROM chips are expected to be shipping ------------ and in good supply....it's nice to see Atari "ON TIME!" ------------------------------------------------------------------------- Latest ST Xformer News ======================= File Transfer Service --------------------- Using the ST with Atari 810 and 1050 disk drives!! -------------------------------------------------- by Darek Mihocka Users of the ST Xformer II emulator are familiar with methods of transfering 8 bit software to the ST. Using modems, null modem cables, and 5 1/4" ST drives (with the Xformer File Xfer Program), it is possible to transfer over files and most boot disks for use with the emulator. I am pleased to announce the development of an interface for the ST, that allows 8 bit peripherals like the 810, 1050 and XF551 disk drives to connect directly to the 520/1040/Mega ST. Other devices, like the 850 interface, modems, and printers can also be connected. Everything just plugs in, so no warranties have to be voided. Using a new version of ST Xformer II not yet released, it is possible to boot directly from these drives, thus allowing copy- protected commercial software to run under the emulator, and eliminating the hassles of the other methods. Now run Text Wizard, B/Graph, Visicalc, APX and Antic disks and many more. This opens new doors to the world of 8 bit emulation. Also, the new Xformer II runs on 512K, something the regular Xformer II can't do. But that's not all! Users of the ST who are not particularly interested in emulation because they still parts of an 8 bit system will also find this useful. This interface allows for file transfers between the 8 bit drives and the 3 1/2" drives, thus allowing easy movement of files back and forth without the need of null modem cables or the 850 interface. So if you have a 520ST with a single disk drive, and were considering buying another drive, consider getting the less expensive 1050 or XF551 drives instead of an ST drive. Users who do not own an 8 bit disk drive, but who can still borrow one for a few days and get their hands on their user group's 8 bit library of disks, will be able to copy them to the ST in as little time as it takes to copy the disks normally. Although I do not plan to develop this feature unless there is specific demand, it is possible to reverse roles and allow the Atari 400/800 computers to access the ST as a virtual disk drive, thus allowing, for example, a BBS running on an Atari 800 to access a 520ST as a large RAMdisk. I will produce the interface, and sell it for about $20 to $30. One of the reasons that kept me from developing this earlier is that I originally wanted the emulator to remain software-only. It will remain this way for users without access to 8 bit peripherals, but for those users who have access to both systems, this is a low cost add-on to increase their enjoyment of their ST. At this time, I am unable to predict how long it will take make this available to all ST users. Hopefully only a few months. Right now the biggest stumbling block is finding those 13 pin 8 bit serial I/O connectors, which seem to be very scarce. Dealers and distributors interested in carrying this product should contact me by voice. Anyone interested in buying one, please phone or write, so that I will know how many interfaces to initially produce. File transfer service --------------------- Any Xformer users who are finding it difficult to port software over, either due to a lack of a modem or null modem cable, should phone me about arranging to send me their disks to copy over to the 3 1/2" format. With my prototype interface, I can copy hundreds of disks a day, and all I require is that you pay for the postage and disks. I would be especially interested in obtaining a large database of public domain 8 bit software (a user group library?). Other Xformer news ------------------ Other improvements are being made to the Xformer. I am working out the details of the full speed emulator, which is now on the horizon. However, I fell that I will prevent me from devoting further time to the Apple and C64 emulators, which have been pretty neglected so far, so I will be making the entire source code to ST Xformer II available. It is written in Laser C, so only Laser C users will be able modify it unless they convert it to another language first. Any developers interested in further improving the Apple and Commodore emulators will then be able to do so. Sometime later in September, I will be putting up the Xformer support BBS, to allow modem users without access to Compuserve, Delphi, or Genie to call and download the latest emulator and 8 bit files. The number will be the same as the current voice number, and operate from around midnight to 6am EST/EDT. Finally, if you are a user of ST Xformer II and have not yet registered your copy, please do so by sending your name, mailing address, phone, and a $20 money order. You will receive a manual and an updated version of the software and 8 bit files. Please indicate whether you want the regular double sided version of Xformer II, or the 512K single sided version of Xformer Junior. The address is: Darek Mihocka 310-D Bluevale St. N. Waterloo, Ontario N2J 4G3 CANADA In the US, remember that postage for Canada is about 5 cents more. The Xformer hotline, voice, and soon by modem, is (519)-747-0386. Other sources of ST Xformer 2.10: --------------------------------- Compuserve - go to the ATARIDEV SIG and enter DL 5 (the Xformer ---------- download library) Delphi - go the ST LOG SIG by typing "gr st" at the main menu. ------ Enter the libraries with the "da" command. Genie - go to the Atari ST roundtable by typing "m 475;3" and ----- download files #7651 thru #7654. and, various ST bulletin boards across the country. ------------------------------------------------------------------------- THIS WEEK'S QUOTE: ================== "A PAT ON THE BACK IS ONLY A FOOT FROM A KICK IN THE BUTT!" ------------------------------------------------------------------------- ST-REPORT Issue #51 SEPT. 5, 1988 (c)'88 APEInc. All Rights Reserved. Reprint permission granted except where noted in the article. Any reprint must include ST-Report and the author in the credits. Views Presented herein are not necessarily those of ST-Report or of the Staff. All items and articles appearing in ST-REPORT are copywrite (c)APEInc. -------------------------------------------------------------------------